Adds .toolbar { ToolbarItem(placement:) { … } } — the first of the two "whole systems" gaps. Until now there was no way to put a button in the navigation bar at all.

Why this can't use the title-sink route

navigationTitle and searchable reach the nav chrome by recording data into the per-screen TitleSink. Toolbar items are views, so they need to be resolved as nodes. They ride instead as hidden children of the screen node — the mechanism sheets and alerts already use — each tagged with its placement, and the interpreter lifts them into the bar's slots.

Placements

navigationBarLeading (sits beside the back button), navigationBarTrailing, principal (replaces the title), bottomBar (a BottomAppBar), and automatic — which goes to the trailing side, as on iOS. A bare view in the builder is wrapped as an automatic item, so .toolbar { Button(…) } works without naming a placement.

Verification

• swift test — new test covering the three placements in order, the bare-view wrapping, and that a toolbar button's callback survives a re-evaluation, 75 total passing
• Emulator (new "Toolbar" catalog screen), every placement rendered in the right slot (screenshot-checked: back arrow → Flag → "Toolbar" → Save, with Bottom action in the bottom bar), and — the part that actually matters, since these items are composed in a different place from where they're declared — each one dispatches into the screen's state: Score went 1 → 11 → 111 tapping Save, Flag, and the bottom action.
• Toggling principal on swapped the title for the item and back, so conditionals inside the toolbar builder resolve correctly too.

Scope

ToolbarItemGroup, .toolbarBackground, .toolbarRole, and toolbar item visibility/customization are not included. Toolbar items attach per navigation screen, the same scope as navigationTitle/searchable.